There is an emerging need for converging fixed and mobile networks, to provide a technology known as “Fixed Mobile Convergence” (FMC). The process of evolving networks to introduce IP-based technologies is common for fixed and mobile networks, which makes convergence easier. Using FMC, mobile and fixed network operators will be able to utilize their network resources more efficiently, reducing both capital and operating expenses. For example, when a user is running an IP-based application such as Multimedia Telephony (MMTel) inside his/her home, it is more efficient to utilize the broadband connectivity of a fixed access network rather than of a cellular telephone network.
User mobility is an important consideration in designing FMC networks. In particular, it is important for a mobile subscriber's home network (that is the network to which the subscriber subscribes, rather than a LAN in the subscriber's home) to always know the subscriber's current location, for example to allow the home network to route voice calls to the subscriber. So-called Proxy Mobile IPv6 (PMIPv6) provides a network based solution to mobility, bringing benefits to mobile operators such as avoiding mobility signaling over the air interface and support for location privacy. In 3GPP Enhanced Packet Core (EPC), PMIPv6 is chosen as a mobility protocol for some interfaces between the network entities (e.g., S2 and S5 interfaces).
The residential network is key to the success of FMC because it is the most commonly used fixed network access for ordinary users. It is necessary to connect mobile phones (hereafter, we use the term “3GPP User Equipment (UE)”) to the EPC through the residential network. Connectivity between the residential network (a Local Area Network) and a Wide Area Network and hence to the EPC is enabled by the so-called “residential gateway” (RGW) which is a relatively inexpensive networking device. A challenge is to provide network-based IP mobility management for 3GPP UEs that are attached to the residential network.
There are various alternatives mechanisms to “connect” 3GPP UEs to the EPC through the residential network. For example, a 3GPP UE may establish an IPSec tunnel to the ePDG inside the EPC, with the ePDG acting as a Mobile Access Gateway (MAG) to provide IP mobility support for the 3GPP UE. On the other hand, an example of a non-tunneled mechanism involves the Broadband Network Gateway (BNG) implementing the functionality of a Proxy MIPv6 (PMIPv6) MAG to provide IP mobility for the 3GPP UEs in a network-based manner.
FIG. 1 illustrates schematically an overview of an FMC network scenario. As shown, a 3GPP UE has an EPC IP address assigned to it in respect of the WLAN interface. Note that the EPC address is derived from the IP address pool owned by the EPC operator. On the other hand, IP address allocation for the non-3GPP terminal is carried out by the RGW and a private IP address (RN IP address) is assigned. The RGW performs NAT/NAPT for IP flows sent from or to non-3GPP UEs.
In non-tunneled scenarios, PMIPv6 is required to provide IP mobility management for the 3GPP UE attached to the residential network. According to the PMIPv6 specification [IETF draft-ietf-netlmm-proxymip6-18, 2008-03-30; IETF draft-ietf-netlmm-mn-ar-if-03, 2008-02-13], the link model for the interface between the AR (MAG) and the MN is assumed to be a point-to-point link. The intentions of the assumption are to overcome the following problems.                IPv6 Neighbor Discovery—If the link is shared by multiple PMIPv6 clients, Neighbor Advertisement messages can be heard by nodes on the link and consequently neighbor cache entries will be created. This may cause disruption of communication between two communicating peers when either of the peers performs handover and moves to a different link.        IPv6 Auto-Configuration—In order to allow a MN to configure its IP address (home address) in a stateless manner, the AR (MAG) needs to send Router Advertisement messages to the multicast address (the IPv6 all node link-local multicast IP address (ff02::1)). However, this is problematic in the PMIPv6 network model because a different prefix is assigned to each MN.        
Although the PMIPv6 specification requires the point-to-point link model which is not the case in the residential network, it is considered that the MNs (3GPP UEs) are capable of sending and receiving IP packets to and from their respective IP unicast addresses (home addresses). Note also that the problem with IPv6 Auto-Configuration can be avoided if any mechanism for stateful address configuration (e.g., DHCP) is in place. The problem with IPv6 Neighbor Discovery remains unresolved, although this is not considered critical because the neighbor cache entry will be deleted when the appropriate timer expires.
As mentioned above, there is generally no problem with IP unicast routing for 3GPP UEs in non-tunneled scenarios. However, there is a problem with IP multicast routing. It should also be noted that there would be a difficulty even in the IP unicast routing if private IP prefix/address is assigned to 3GPP UE.
Considering further the problem arising as a result of IP multicast routing, this arises because the BNG and RGW cannot determine under which IP session a given downstream/upstream IP packet should be handled. Taking an example of downstream IP routing, suppose that the BNG (MAG) sends a downstream IP packet bound for an IP multicast address (e.g., ff02::1) which is actually intended for a specific PMIPv6 client (3GPP UE). Since the BNG is the sender of the message, it will be aware of the IP session associated with the PMIPv6 client. Therefore, the packet is delivered to the RGW without problem. However, the RGW does not have any information to determine which node the IP packet should be delivered to. Note that the destination IP address included in the IP header is a multicast IP address. As for upstream IP packet processing, exactly the same issue arises at the BNG.
The problem with IP unicast routing occurs if “private” IP prefixes/addresses are assigned to 3GPP UEs. For example, suppose that two 3GPP UEs (MN1 and MN2) from different mobile network providers (MNPs) are connected to the same residential network. If both of the mobile network providers independently assign private IP addresses/prefixes to their 3GPP UEs, then there is a possibility that the 3GPP UEs are allocated the same IP address/prefix. If this is the case, the BNG and RGW face exactly the same problem (as mentioned above) in handling IP multicast packets mentioned above. FIG. 2 illustrates schematically an example network configuration in which multiple 3GPP UEs are attached to a residential network, with the UEs being allocated private EPC addresses.